# 前言

在上一章，我们学习了 k8s 如何处理 Pod 的滚动发布，滚动发布的主要目的是做到零宕机完成环境更新。

那么问题来了， kubernetes 到底是以什么依据，判断我们 Pod 启动成功的？

# 什么是健康度检查？

我们在之前的部署知道，当 Pod 的状态为 Running 时，该 Pod 就可以被分配流量（可以访问到）了。但是，这种检查方式对于一部分Pod来说是不靠谱的。

有写过后端的同学可能了解，一般一个后端容器启动成功，不一定不代表服务启动成功。在后端容器启动后，部分 MySQL，消息队列，配置文件等其他服务的连接还在初始化，但是容器的外部状态却是启动成功。在这种情况下，直接去访问 Pod 必然会有问题。

那么有没有什么办法可以自己控制流量分配的标准呢？这就要提到我们下面要写到的概念 —— 服务探针

# 什么是服务探针？

探针一词，和古代银针试毒的概念差不多 —— 将银针放入水中，如果银针变黑，则代表有毒；如果没有变黑，则代表正常。

那么在 kubernetes 中，探针用来检测 Pod 可用情况的。在 kubernetes 中，有三种探针可以使用：

# 1. 存活探针 LivenessProbe

第一种是存活探针。存活探针是对运行中的容器检测的。如果想检测你的服务在运行中有没有发生崩溃，服务有没有中途退出或无响应，可以使用这个探针。

如果探针探测到错误， Kubernetes 就会杀掉这个 Pod；否则就不会进行处理。如果默认没有配置这个探针， Pod 不会被杀死。

# 2. 可用探针 ReadinessProbe

第二种是可用探针。作用是用来检测 Pod 是否允许被访问到（是否准备好接受流量）。如果你的服务加载很多数据，或者有其他需求要求在特定情况下不被分配到流量，那么可以用这个探针。

如果探针检测失败，流量就不会分配给该 Pod。在没有配置该探针的情况下，会一直将流量分配给 Pod。当然，探针检测失败，Pod 不会被杀死。

# 3. 启动探针 StartupProbe

第三种是启动探针。作用是用来检测 Pod 是否已经启动成功。如果你的服务启动需要一些加载时长（例如初始化日志，等待其他调用的服务启动成功）才代表服务启动成功，则可以用这个探针。

如果探针检测失败，该 Pod 就会被杀死重启。在没有配置该探针的情况下，默认不会杀死 Pod 。在启动探针运行时，其他所有的探针检测都会失效。

# 总结

Kubernetes 里面内置了三种健康度探针，可以分别在启动时和运行时为我们的 Pod 做检测。下面是一个对比表格：

当然，配置的方式也很简单。我们只需要在 containers.livenessProbe/readinessProbe/StartupProbe 下配置即可

# 三种方式探测方式

上面我们了解了探针的几种类型。这里就了解下探针的几种探测方式。虽然探针类型的不同，触发的阶段，但是其探测方式都是一样的，检测的 API 也是一样的。有以下三种检测方式：

# 1. ExecAction

这种方式是通过在 Pod 的容器内执行预定的 Shell 脚本命令。如果执行的命令没有报错退出（返回值为0），代表容器状态健康。否则就是有问题的。

我们以下面为例：这是一个创建 Pod 的配置文件模版。可以看到，里面配置了一个存活探针 LivenessProbe + ExecAction 命令检测。其中，livenessProbe.exec 代表去执行一段命令， command 则是要执行的探针命令。 livenessProbe 代表声明一个存活探针。

apiVersion: v1
kind: Pod
metadata:
  labels:
    test: liveness
  name: liveness-exec
spec:
  containers:
  - name: liveness
    image: registry.aliyuncs.com/google_containers/busybox
    args:
    - /bin/sh
    - -c
    - touch /tmp/healthy; sleep 30; rm -rf /tmp/healthy; sleep 600
    livenessProbe:
      exec:
        command:
        - cat
        - /tmp/healthy
      initialDelaySeconds: 5
      periodSeconds: 5

当我们的 Pod 启动成功时，会自动执行下面的这个命令：新建一个 /tmp/healthy 文件 => 睡眠 30 秒 => 删除 /tmp/healthy 文件 => 睡眠 600 秒。

touch /tmp/healthy; sleep 30; rm -rf /tmp/healthy; sleep 600

而我们的探针检测，在第一次探测等待5秒后，会去尝试访问 /tmp/healthy 文件来判断检测结果。然而，只有在 Pod 运行的前30秒，这个文件才存在。在第30秒后，文件被删除，探针就访问不到这个文件了，于是只好